Stx Monthly Trades ProfitMonthly profit displays profits in a grid and allows you to know the gain related to the investment during each month.
The profit could be computed in terms of gain/trade_cost or as percentage of equity update.
Settings:
- Profit: Monthly profit percentage or percentage of equity
- Table position
This strategy is intended only as a container for the code and for testing the script of the profit table.
Setting of strategy allows to select the test case for this snippet (percentage grid).
Money management: not relevant as strategy is a test case.
This script stand out as take in account the gain of each trade in relation to the capital invested in each trade. For example consider the following scenario:
Capital of 1000$ and we invest a fixed amount of 1000$ (I know is too risky but is a good example), we gain 10% every month.
After 10 months our capital is of 2000$ and our strategy is perfect as we have the same performance every month.
Instead, evaluating the percentage of equity we have 10% the first month, 9.9% the second (1200$/1100$ - 1) and 5.26% the tenth month. So seems that strategy degrade with times but this is not true.
For this reason, to evaluate my strategy I prefer to see the montly return of investment.
WARNING: The strategy provided with this script is only a test case and allows to see the behavior with different "trades" management, for these reason commision are set to zero.
At the moment only the provided test cases are handled:
test 1 - single entry and single exit;
test 2 - single entry and multiple exits;
test 3 - single entry and switch position;
Cerca negli script per " TABLE"
@tk · spectral█ OVERVIEW
This script is an indicator that helps traders to identify the price difference between spot and futures of the current crypto plotted into the chart. It works in both types of markets, when the chart is plotting the crypto in spot market, it will compare with its respective futures ticker and vice-versa. If the current asset isn't a crypt ticker, the indicator will not be plotted into the chart.
█ MOTIVATION
Since crypto's derivative market is based on spot market asset's price, to calculate the arbitrage mechanisms that attempts to balance the asset price, this indicator can help traders to identify some spot and futures price divergence that can create an anomaly of funding rate and can push it to an extreme negative — or positive — rate. So, easing to track the price difference between both markets will bring more evidences to identify an artificial price move, specially in crypto assets with low market cap.
█ CONCEPT
The trading concept to use this indicator is the concept of the arbitrage machamism created by exchanges that calculates the funding rate based on spot and futures price difference that will vary from exchange to exchange. This strategy don't works alone. It needs to be aligned together with others indicators like Exponential Moving Averages, Chart Patterns, Support and Resistance, and so on... Even more confluences that you have, bigger are your chances to increase the probability for a successful trade. So, don't use this indicator alone. Compose a trading strategy and use it to improve your analysis.
█ CUSTOMIZATION
This indicator allows the trader to customize the following settings:
GENERAL
Text size
Changes the font size of price difference table to improve accessibility.
Type: string
Options: `tiny`, `small`, `normal`, `large`.
Default: `small`
Position
Changes the position of price difference table.
Type: string
Options: `top_left`, `top_center`, `top_right`, `middle_left`, `middle_center`, `middle_right`, `bottom_left`, `bottom_center`, `bottom_right`.
Default: `bottom_right`
Pair Quote
The ticker quote symbol that will be used to base the ticker comparison from spot to futures (e.g. BTCUSDT which `USDT` is the quote. ETHBTC which `BTC` is the quote).
Type: string
Default: USDT
Spectrum Color
The color of the spectrum candles. Spectrum candles are the candles of the opposite market. If the current ticker is in the spot market, the spectrum candles will be the price of the futures market.
Type: color
Default: #434651
█ FUNCTIONS
The indicator contains the following functions:
stripStarts(src, str)
Strips a defined pattern from a string.
Parameters:
src: (string) Source string
str: (string) String pattern to be stripped from start of source string.
Returns: (string) Stripped string with matched regex pattern.
All Candlestick Patterns Screener [By MUQWISHI]▋ INTRODUCTION :
The Candlestick Patterns Screener has been designed to offer an advanced monitoring solution for up to 40 symbols. Utilizing a log screener style, it efficiently gathers information on confirmed candlestick pattern occurrences and presents it in an organized table. This table includes essential details such as the symbol name, signal price, and the corresponding candlestick pattern name.
_______________________
▋ OVERVIEW:
_______________________
▋ CREDIT:
Credit to public technical “*All Candlestick Patterns*” indicator.
_______________________
▋ USAGE:
_______________________
▋ Final Comments:
For best performance, add the Candlestick Patterns Screener on active symbol chart like QQQ, SPY, AAPL, BTCUSDT, ES, EURUSD or …etc.
Candlestick patterns are not a major concept to build a trading decision.
Personally, I see candlestick patterns as a means to comprehend the psychology of the market, and help to follow the price action.
Please let me know if you have any questions.
Thank you.
Z-Score Retracement Indicator Releasing the Z-Score Retracement Indicator
What it does:
The Z-Score retracement indicator operates similarly to Fibonacci retracements. It calculates the average, standard deviation and Z-Scores of a user defined period and will plot out the various Standard Deviation levels and price targets based on the period under analysis.
It will visually display the distance from the mean and which price targets correspond to which standard deviation. It is intended to aid traders in determining where the mean is and to calculate the probability of price targets and the probability of a regression to the mean.
How do you use it?
When you launch the indicator, it will ask you to identify the start period. I always try to identify periods where the most recent uptrend or downtrend has started, and then start the analysis from that point. When you plot it, the indicator will display the current strength of the trend in the same way that a regression or log-linear regression indicator would, by displaying the Pearson Correlation Coefficient:
Unlike with linear regression or log-linear regression, you don't necessarily need to have a strong up or downtrend to use the indicator, however it is ideal to find an area with a clear trend.
From there, you can clearly see the standard deviation zones:
The indicator will also display the current Standard Deviation of the last close price.
The centre line (a Z-Score of 0) corresponds to absolute neutrality and would be a regression to the mean. The price target for this area is also listed.
If you want to calculate the price of a specific Standard Deviation, you can! Launch the settings and select the input you would like:
Simply select whether you want to convert a Standard Deviation Z-Score to price or price to Z-Score. Then input the variable into the appropriate field. The indicator will then display the results in a table at the top right of the chart:
In the above image, you can see that a Z-Score of 0 (indicating absolute neutrality) on QQQ is equivalent to a price of 299.
Calculating Probability:
You can calculate probability by reference a Z-Score Table. I have discussed this in my previous Z-Score based indicators, but essentially, the rule of thumb is this:
Anything over + 2 standard deviations corresponds with roughly less than a 5 to 10% chance of continuation higher. I encourage you to check out the writeup on my Z-Score Probability Indicator for more information on the price use of Z-Score for probability determinations.
Concluding remarks:
And that is the indicator! Its pretty straight forward and its intended to be an added tool for regression and log-linear regression based traders to help visualize the actual distance from the mean a ticker is currently trading at.
Another thing to keep in mind is you can use this on the very small time frames as well. I have used this for day trading on the 5 and 1 minute timeframe to determine "regressions to the mean" on a much smaller level. Like here:
That's the indicator!
Hope you enjoy, leave your questions, comments and suggestions below, safe trades everyone!
RSI and Stochastic Probability Based Price Target IndicatorHello,
Releasing this beta indicator. It is somewhat experimental but I have had some good success with it so I figured I would share it!
What is it?
This is an indicator that combines RSI and Stochastics with probability levels.
How it works?
This works by applying a regression based analysis on both Stochastics and RSI to attempt to predict a likely close price of the stock.
It also assess the normal distribution range the stock is trading in. With this information it does the following:
2 lines are plotted:
Yellow line: This is the stochastic line. This represents the smoothed version of the stochastic price prediction of the most likely close price.
White Line: This is the RSI line. It represents the smoothed version of the RSI price prediction of the most likely close price.
When the Yellow Line (Stochastic Line) crosses over the White Line (the RSI line), this is a bearish indication. It will signal a bearish cross (red arrow) to signal that some selling or pullback may follow.
IF this bearish cross happens while the stock is trading in a low probability upper zone (anything 13% or less), it will trigger a label to print with a pullback price. The pullback price is the "regression to the mean" assumption price. Its the current mean at the time of the bearish cross.
The inverse is true if it is a bullish cross. If the stock has a bullish cross and is trading in a low probability bearish range, it will print the price target for a regression back to the upward mean.
Additional information:
The indicator also provides a data table. This data table provides you with the current probability range (i.e. whether the stock is trading in the 68% probability zone or the outer 13, 2.1 or 0.1 probability zones), as well as the overall probability of a move up or down.
It also provides the next bull and bear targets. These are calculated based on the next probability zone located immediately above and below the current trading zone of the stock.
Smoothing vs Non-smoothed data:
For those who like to assess RSI and Stochastic for divergences, there is an option in the indicator to un-smooth the stochastic and RSI lines. Doing so looks like this:
Un-smoothing the RSI and stochastic will not affect the analysis or price targets. However it does add some noise to the chart and makes it slightly difficult to check for crosses. But whatever your preference is you can use.
Cross Indicators :
A bearish cross (stochastic crosses above RSI line) is signalled with a red arrow down shape.
A bullish cross (RSI crosses above stochastic line) is signalled with a green arrow up shape.
Labels vs Arrows:
The arrows are lax in their signalling. They will signal at any cross. Thus you are inclined to get false signals.
The labels are programmed to only trigger on high probability setups.
Please keep this in mind when using the indicator!
Warning and disclaimer:
As with all indicators, no indicator is 100% perfect.
This will not replace the need for solid analysis, risk management and planning.
This is also kind of beta in its approach. As such, there are no real rules on how it should be or can be applied rigorously. Thus, its important to exercise caution and not rely on this alone. Do your due diligence before using or applying this indicator to your trading regimen.
As it is kind of different, I am interested in hearing your feedback and experience using it. Let me know your feedback, experiences and suggestions below.
Also, because it does have a lot of moving parts, I have done a tutorial video on its use linked below:
Thanks for checking it out, safe trades everyone and take care!
Cloud Bunching [5ema]Reused some functions from (i believe made by):
©paaax: The table position function.
@QuantNomad: The function calculated value and array screener for 40+ instruments .
How it uses:
Gives signal when the cloud is bunching with ratio smaller than the set ratio and the close price breaking out the cloud.
Track 40 different symbols, on any timeframe to follow and alert.
When a symbol has a signal, it will display on the chart and send an alert.
How it works:
The cloud created by 5 EMA (20, 50, 200, 460, 610). Upper Cloud is max EMA , Lower Cloud is min EMA . Center line is averange (5 EMA )
If the ratio upper / lower < input bunching (%) -> change color of cloud.
Get the signal if: the close price break out cloud (with bar is shooting, or hammer ,...) and high volume (or not).
With another symbols (max 40 ) also use that function with any time frame. By request.security() and array function.
How it setting:
Change the bunching rate (%) of the clouds for any symbols.
Change the percentage (%) of the close price that breaks out of the bunching cloud.
Choose volume condition.
Show or turn off the cloud, table.
Select the symbol to follow.
Choose a timeframe to follow other symbols.
----
This indicator is for reference only, you need your own method and strategy.
If you have any questions, please let me know in the comments.
Tailored-Custom Hamonic Patterns█ OVERVIEW
We have included by default 3 known Patterns. The Bat, the Butterfly and the Gartley. But have you ever wondered how effective other,
not yet known models could be? Don't ask yourself the question anymore, it's time to find out for yourself! You have the option to customize
your own Patterns with the Backtesting tool and set Retracement Ratios and Targets for your own Patterns. In addition to this, in order to determine
the Trend at a glance and make Pattern detection more efficient, we have linked the calculation of Patterns to Bands of several types to choose
from (Bollinger, Keltner, Donchian) that you can select from a drop-down menu in the settings and play with the Multiplier
and the Adaptive Length of the Patterns to see how it affects the success rate in the Backtesting table.
█ HOW DOES IT WORK?
- Harmonic Patterns
-Pattern Names, Colors, Style etc… Everything is customizable.
-Dynamic Adaptative Length with Min/Max Length.
- XAB/ABC Ratio
-Min/Max XAB/ABC Configurable Ratio for each Pattern to create your own Patterns.
(This is really the particular option of this Indicator, because it allows you to be able to Backtest in real time
after having played at configuring your own Ratios)
- Bands
-Contrary to the original logic of the HeWhoMustNotBeNamed script, here when the price breaks out of the upper Bands
(example, Bollinger band, Keltner Channel or Donchian Channel) , with a predetermined Minimum and Maximum Length and Multiplier, we can consider
the Trend to be Bearish (and not Bullish) and similarly when the price breaks down in the lower band, we can consider the Trend
to be Bullish (not Bearish) . We have also added the middle line of the Channels (which can be useful for 'Scalper' type Traders.
-The Length of the Bands Filter is directly related to the Dynamic Length of the Patterns.
-You can use a drop-down menu to select from the following Bands Filters :
SMA, EMA, HMA, RMA, WMA, VWMA, HIGH/LOW, LINREG, MEDIAN.
-Sticky and Adaptive Bands options has been included.
- Projections
-BD/CD Projection Ratio configurable for each Pattern.
(Projections are visible as Dotted Lines which we can choose to Extend or not)
- Targets
-Target, PRZ and Stop Levels are set to optimal values based on individual Patterns. (The PRZ Level corresponds to point D
of the detected Pattern so its value should always be 0) but you can change the Targets value (defined in %) as you wish.
Again here, you have the option to fully configure the Style and Extend the Lines or not.
- Backtesting Table
-As said previously, with the possibility of testing the Success Rate of each of the 3 Customizable Patterns,
this option is part of the logic of this Indicator.
- Alerts
-We originally believe that this Indicator does not even need Alerts. But we still decided to include at least one Alert
that you can set for when a new Pattern is detected.
█ NOTES
Thanks to HeWhoMustNotBeNamed for his permission to reuse some part of his zigzag scripts.
Remember to only make a decision once you are sure of your analysis. Good trading sessions to everyone and don't forget,
risk management remains the most important!
Simple RangeThe daily price range is a good proxy to judge an instrument’s volatility. I have combined multiple concepts in this indicator to display information regarding the daily price range & its volatility.
A trading period's range is simply the difference between its high and the low. This script shows the daily high-to-low range of the price as a column chart. It has 3 main components:
1. Narrow-range days (NR7) & Wide-range Days (WR20) - as plot columns
Original concept from Thomas Bulkowski
Modified from "NR4 & NR7 Indicator" script by theapextrader7
Modified from "WR - BC Identifier" script by wrpteam2020
Narrow range days mark price contractions that often precede price expansions. This script uses NR7 (narrow range 7) as a narrow-range day. This value can be changed by the user if, instead of an NR7, he or she wishes to use NR4 or NR21, or any other interval of his or her choice. NR7 is an indecisive trading day in which the range is narrower than any of the previous six days (a total of 7 days). This is a popular concept given by Thomas Bulkowski. A breakout is said to occur when price closes above the top or below the bottom of the NR7. Upside breakout of an NR 7 candle with high volumes indicates bullishness.
Similarly, highs & lows of wide-range bars (on big volumes) are also significant reference levels for price. Wide-range candle are identified by size of the body candle (open - close). The script compares the size of previous 20 candles to identify WR20 candles. This value can also be changed by the user.
The script shows NR7 & WR20 as orange & blue bars, respectively.
The user can also turn on the option to identify a big high-to-low range candle greater than a pre-defined threshold (default is 5%). These show up as green or red bars.
2. TTM Squeeze - as background
Original concept from John Carter's book "Mastering the Trade"
Based on "Squeeze Momentum Indicator" script by LazyBear
John Carter’s TTM Squeeze indicator looks at the relationship between Bollinger Bands and Keltner's Channels to help identify period of volatility contractions. Bollinger Bands being completely enclosed within the Keltner Channels is indicative of a very low volatility. This is a state of volatility contraction known as squeeze. Using different ATR lengths (1.0, 1.5 and 2.0) for Keltner Channels, we can differentiate between levels of squeeze (High, Mid & Low compression, respectively). Greater the compression, higher the potential for explosive moves.
In the script, the High, Mid & Low compression squeezes are depicted via the background color being red, orange, or yellow, respectively.
3. Average Daily Range - as table
Original idea by alpine_trader
Modified from "ADR% - Average Daily Range % by MikeC" script by TheScrutiniser
Average Day Range (ADR) tells how much the price moves between the high and low on a given day. This is the day Range, which is then averaged to create ADR. The script uses an average of the last 20 days to calculate the ADR. Unlike ATR (Average True Range), this excludes Gaps.
The script displays the ADR as a % value in a table.
If you want to find stocks that move a lot on an average on most days, then look for stocks that have ADR% of 5% or more.
If you prefer lower volatility stocks, focus on stocks with lower ADR% values, such as 2% or less.
How it comes together
For a bullish "momentum burst", or a velocity trade:
Select stocks with Average Day Range % (ADR) greater than 5
Identify significant reference price levels via highs & lows of WR20 bars (on big volumes)
Wait for a decent mid-to-high compression squeeze
Look for clusters of NR7 candles in the consolidation
Any breakout from this consolidation should be accompanied by more than average (preferably pocket pivot) volumes
Manage tradeThis indicator is intended to simulate a second entry to adjust the average price.
INPUTS:
Current price || Coins -> Current price, your first entry || Initial amount of coins
Simulate entry || Coins -> New entry, from this entry the average price will be calculated || new amount of coins
Simulate partial % || Coins -> Percentage over current price or average price || Amount of coins withdrawn
* Currency conversion
Value $ || Target price -> amount or coins, example: 25 dolar or 25 busd || Acquisition target price, returns desired coin amount, visible in table.
Table information:
simbol = current symbol
current price = First entry price
total coins = Total coins from first entry
profit or loss = self explanatory
update value = increases or decreases according to profit or loss
Partial profit = partial simulation result,
$ ⮕ ₿ = total amount of currencies in the conversion
Pro Trading Art - Top N Candle's Gainers/Losers(1-40)Top Gainer/Loser Screener.
Explanation :
With the help of this indicator you can filter top Gainer or Loser in comparison with previous selected range. Suppose you select 5 period inside input tab then this indicator will filter top gainer or losers in 5 days.
Input Parameter:
Timeframe: You can change timeframe of chart. Default timeframe is same as chart.
Period: To select range of candle. Default 5. Means how much price changed in previous 5 candle.
Top : Dropdown option to select top Gainer or Losers
Table Location: Where you want to place your table.
Watchlist Group: You can create watchlist for screener.
(Quartile Vol.; Vol. Aggregation; Range US Bars; Gaps) [Kioseff]Hello!
This indicator is a multifaceted tool that's, hopefully, useful for price action and volume analysis.
(This script makes use of the newly introduced "text_font" parameter)
With this script you'll have access to:
Range US Chart
Volume Aggregation Chart
Gaps Chart
Volume by Quartile
Consequently, you'll have access to:
First Quartile Volume Threshold
Second Quartile Volume Threshold
Third Quartile Volume Threshold
90th Percentile Volume Threshold
Fourth Quartile Volume Threshold
Q2 - Q1 Dispersion
Q3 - Q2 Dispersion
Q4 - Q3 Dispersion
Quartile Deviation
Interquartile Range
Avg. "n" bar return following "high" volume
Avg. "n" bar positive return following "high" volume
Avg. "n" bar negative following "high" volume
# of Positive Returns Following a Gap
# of Negative Returns Following a Gap
# of Gaps
# of Up Gaps
# of Down Gaps
Average # of bars to fill Up Gaps
Average # of bars to dill Down Gaps
Average Gap Up % increase
Average Gap Down % decrease
Cumulative % increase of all Up Gaps
Cumulative % decrease of all Down Gaps
Sort gaps by distance from price
Hide gaps that price substantially deviates from (gaps will reappear when price trades near the gap)
Segment Range US bars by date
Manually configure Range US price thresholds
Identify "congestion" areas with Range US bars
Range US Levels that must be exceeded for a new Range US bar to produce
Manually configure cumulative volume threshold for Volume Aggregation bars
Segment Volume Aggregation bars by date
Largest Volume Aggregation bar increases
Largest Volume Aggregation bar decreases
Calculate log returns after "high" volume sessions
Quartile Volume
The Quartile Volume portion of the script segments price/volume intervals by quartile.
The image above shows features of the indicator.
For statistics, the following metrics are recorded:
First Quartile
Second Quartile
Third Quartile
90th Percentile
Fourth Quartile
Q2 - Q1 Dispersion
Q3 - Q2 Dispersion
Q4 - Q3 Dispersion
Quartile Deviation
Interquartile Range
Color-coordinated price bars (by volume quartiles)
The percent rank for the volume of the current bar
Avg. "n" bar return following "high" volume
Avg. "n" bar positive return following "high" volume
Avg. "n" bar negative following "high" volume
The script colors bars via gradient.
By default, bars are colored lime when volume for the interval is "high" (exceeds upper quartile thresholds). The greener the bar, the higher the volume for the interval.
Bars are colored red when volume for the interval is "low" (fails to exceed lower quartile thresholds). The redder the bar, the lower the volume for the interval.
Naturally, brownish-colored bars reflect a volume interval that concluded near the median.
The image above exemplifies the process. This feature might be useful to categorize / objectively define high-volume clusters, low-volume clusters, high-volume price moves, low-volume price moves, etc.
For greater precision, you can select to color bars by volume quartile they belong to.
The image above shows color-coordinated price bars. More details shown in the image.
Additionally, you can select to plot the quartile/percentile that a price bar belongs to on the chart.
The image above shows price bars numbered by the volume quartile they belong to.
The script will distinguish successive 90th percentile violations, superimpose a linear regression channel atop the data sequence, and record pertinent statistics.
The image above shows the process.
Lastly, the user can plot an anchored VWAP using a built-in time function.
The image above shows the anchored VWAP.
Range US Chart
A Range US chart operates irrespective of time and volume - simply - bars produce after a user-defined price move is achieved/exceeded in either direction. A range us chart produces “trend candles” and “reversal candles”. A reversal candle always moves against the most immediate bar; a trend candle always moves in favor of the most immediate bar. The user defines the dollar amount price must travel up/down for a trend candle to fulfill, and for a reversal candle to fulfill.
Note: if a “down reversal” candle (red) Is produced, it’s impossible for the next candle to also be a down reversal candle - for the downside move to continue the criteria for a down trend candle must be fulfilled. Similarly, if an “up reversal” candle (green) Is produced, it’s impossible for the next candle to also be an up reversal candle - for the upside move to continue, the criteria for an uptrend trend candle must be fulfilled. Consequently, Range US bars frequently trade at the same level for extended periods. This is intentional, as this chart type is theorized to “filter noise” (whether Range US charts fulfill this theory is to your discretion).
Lastly, if an up trend candle (green) is produced, the next candle cannot be up a reversal up candle - only a trend up candle or reversal down candle can produce - vice versa for a trend down candle (the subsequent candle cannot be a reversal down candle). In this sense, an uptrend continues on successive trend up candles; a down trend continues on successive trend down candles.
The image above exemplifies Range US chart functionality.
The lower-right stats table shows the requisite price move for a "Trend" candle to produce and for a "Reversal" candle to produce.
The default settings for this chart time automatically calculate the required "Trend" candle price move and the required "Reversal" candle price move. However, both settings are configurable.
The image above shows manually configured parameters for a trend bar and reversal bar to produce. This feature allows the user to replicate the Range US chart hosted on extrinsic charting platforms.
However, please consider that this script does not use tick data; 1-minute OHLC data is used for calculations.
Consequently, configuring the trend bar and reversal bar requirement too low may return inaccurate data. For instance, if you set trend candles to form after a $1 price move then trend candles will form if price moves up $1 from a green Range US bar or down $1 from a red Range US bar. This is sufficient for lower priced assets; however, if you were trading, for instance, Bitcoin - a $1 price move can happen numerous times in one minute. This script can’t plot bars and record data until a 1-minute bar closes and a new 1-minute bar opens. Further, if Bitcoin moves up $1 twenty times and down $1 twenty times in a 1-minute bar - your Range US chart will record such variations as one price move. This data is inaccurate and likely useless.
To counter this quandary, a warning message will appear if you configure trend bar price moves or reversal bar price moves too low.
The image above shows the concealable warning message.
The image above is a flow diagram (made with shaky hands) illustrating the Range US bar formation process.
A google search will return additional information on the Range US chart type.
Volume Aggregation Bars
TradingView user and member of the TradingView Discord server @ferreirajames informed me of the Volume Aggregation chart type. The user commented in the "Suggestions" channel for the TradingView Discord server asking for the Volume Aggregation chart type. As an interim fix, I tried my hand at recreating the process, which is available in this script.
Similar to the Range US chart type, Volume Aggregation bars aren’t bound to a time-axis; the bars form after a user-defined, cumulative amount of volume is achieved or exceeded. Consequently, once the cumulative amount of volume is achieved or exceeded - a bar is produced at the corresponding price level.
Underlying theory: The chat type is conducive to identifying price levels where traders are “trapped”. Whether the process adequately distinguishes this circumstance is to your discretion.
The image above exemplifies the Volume Aggregation chart type.
Regardless of the current price, Volume Aggregation bars for after a requisite amount of volume is achieved/exceeded. Tick data isn't used; therefore, remainder values are carry over.
By default, the script automatically calculates a proportional cumulative volume total to dictate the formation of Volume Aggregation bars. However, the cumulative threshold is configurable.
The image above shows Volume Aggregation bars forming subsequent a user-defined cumulative volume total being exceeded.
Note: This chart type uses OHLC data from the timeframe of your chart. Therefore, for instance, setting the volume threshold too low will produce inaccurate, useless data.
A warning message will appear for such occurrence.
Gaps
The indicator incorporates a "Gaps" chart type.
The image above shows accompanying features.
A list of all unfilled gaps is accessible - gaps for this list are sorted by distance from current price.
Partially filled gaps are displayed in the corresponding gap box - the percentage amount the gap was filled is also displayed.
Gap statistics show:
# of Gaps
# of Up Gaps
# of Down Gaps
Average # of bars to fill Up Gaps
Average # of bars to dill Down Gaps
Average Gap Up % increase
Average Gap Down % decrease
Cumulative % increase of all Up Gaps
Cumulative % decrease of all Down Gaps
Naturally, there may be gaps formed thousands of bars ago that aren't close to price. Showing these gaps on the chart will "scrunch" the y-axis and make prices indistinguishable.
I've added a setting that allows the user to hide gaps that are "n" % away from the current price. The gap, if unfilled, will reappear when price trades within the user-defined percentage.
The image above shows an example. There's an unfilled down gap that's "hidden" because the current price is a further % away from price than what I've specified in the settings (1%). When prices trade back within 1% of the gap - it will reappear.
The image above shows the process in action. Prices moved back within 1% (can be any %) of the gap; therefore, it reappeared on the chart.
You can also set the % distance a gap must achieve for it to be considered a gap, recorded and plotted. Additionally, you can select to "visualize" gaps. Similar to the Range US chart and the Volume Aggregation chart, this setting will bars reflecting the most recent sequence of gaps - date and percentage distance of the gap are superimposed atop the bar.
Let me know if there's anything else you'd like included!
Note: The initial compilation time for this script is.... high. However, once the script's compiled, calculation load times are quick and you can sift through assets and timeframes relatively quick.
There's also a setting to "Improve Load Times" in the user-inputs table. This setting only improves the load times for post-compilation calculations and plots. The initial compilation load time is unchanged. Simply, once the indicator has "first loaded", all subsequent loads are quick.
Thank you! (:
Custom Multi-Timeframe IndicatorIt's a pretty simple example of a nice custom screener you can run for multiple timeframes. This is an RSI screener, but you can easily change the function for your own Indicator.
Screener displays:
Last value of the instrument
RSI value for up to 10 instruments / 4 timeframes.
In Parameters you can change:
4 timeframes
10 instruments
Parameters for RSI
Styling parameters for table
If the selected timeframe will be lower than the current one you will receive a warning message in a table.
Thanks to @MUQWISHI to help me code it.
Disclaimer
Please remember that past performance may not be indicative of future results.
Due to various factors, including changing market conditions, the strategy may no longer perform as well as in historical backtesting.
This post and the script don’t provide any financial advice.
Weekly Returns with BenchmarkSome time ago I published Monthly returns table. Now It's time for weekly one.
To get it work you need a pretty big screen, but I hope it will be useful for some of you.
Features of this table includes:
Display weekly returns of your strategy, benchmark, and alpha over this benchmark.
Select benchmark to be another instrument
Select the date from which you want to compute monthly returns
Show/hide benchmark and alpha
Choose colors for gradient for gain/loss values
Use it with any type of strategy
Use it with replay
Thanks to @MUQWISHI to help me coding it.
It's not about the strategy itself but the way you display returns on your chart. So pls don't critique my choice of the strategy and its performance 🙂
Disclaimer
Please remember that past performance may not be indicative of future results.
Due to various factors, including changing market conditions, the strategy may no longer perform as well as in historical backtesting.
This post and the script don’t provide any financial advice.
VIX Cheat SheetHello!
This indicator - "VIX Cheat Sheet" - performs several calculations for $VIX against the asset on your chart. However, using $VIX as a risk proxy or volatility metric often fails beyond large-cap U.S equities. To remedy this, the VixFix indicator is included in the script; you can select whether the script performs calculations for an asset against $VIX or against VixFix (i.e. Forex, Crypto)
Measured are: $VIX correlation to an asset's price fluctuations, the average close-to-close gain/loss subsequent a $VIX/VixFix close above the upper Bollinger Band, the average 5-session gain/loss following the same occurrence in addition to the average 10-session gain/loss, all close-to-close, 5 session, and 10-session gains/losses are stored as tooltips for labels on the chart. The current close-to-close percentage gain/loss for $VIX and VixFix are displayed on the chart.
Displayed in the example image is a box incorporating $VIX price data alongside an upper Bollinger Band and lower Bollinger Band. The data isn't cast to its own price scale but is helpful for quick interpretation of $VIX fluctuations. You can select to plot VixFix data in the box in the user inputs table.
Displayed in the second example image is a semi-transparent blue box encompassing all price moves that occurred when $VIX measured above $40 for at least ten consecutive sessions. The largest percentage close-to-close loss is displayed below the box.
Also illustrated is a red label that appears when $VIX or VixFix closes above the upper Bollinger Band. The indicator will calculate and display the performance of the asset for the subsequent 10 sessions, to which the red label will disappear and all data stored as a tooltip in the blue labels stating "VIX Closed Above Upper Band" or "VixFix Closed Above Upper Band".
To reduce chart clutter, a label and line combination marking all $VIX closes above the upper Bollinger Band was not included. Instead, bar color changes were added. When "$VIX" is selected in the user inputs table the indicator will mark all sessions in which $VIX closed above the upper band as blue, in addition to plotting $VIX price data in the dynamic black box. When "VixFix" is selected, the indicator will mark all sessions where VixFix closed above the upper band as purple; the VixFix indicator will be plotted in the black box.
Be sure to hover over labels to access tooltip information; try the indicator with bar replay!
Financial GrowthThis indicator will acquire the financial data provided by Tradview.
the data is compare between Quarter, Annual and TTM in term of percent of growth.
YoY, QoQ and CAGR is also available by this script (The minimum is 4).
in addition, ploting of data, label and table also available (you can check the mark to toggle on / off).
Data : Revenue, Net Income, EBITDA, EPS, DVPS, Free Cash Flow and Forward PE .
How to use it.
just select the financial data, period and size of data to compare.
you can check the box to toggle the plotting line, label and table.
Enjoy.
40 crypto screener [LUPOWN]// ENGLISH
This indicator shows two tables, with 10 assets each, they can be currencies, stocks or cryptos, the columns can be changed to the information you want to see, among the options are price or change (change in percentage of the candle in the temporality where you are seeing it), TL are buy or sell signals according to the Latin trading strategy (Squeeze momentum combined with ADX) buy if the momentum changes to range or rise and the ADX has a negative slope, sell if the momentum changes to range or fall and The ADX has a negative slope, the signals are not 100% effective, you must support it with price action and market speculation, directionality in the momentum, slope of the ADX, if there is divergence in the momoentum squeeze, lux something and cipher use an indicator of Lazy bear, lux something signals when two wave trends cross and the cipher signals when the wave trend crosses above or below the 0 point.
You can choose between seeing one or two tables, this so that it can be seen on small screens, there is also the option to hide the tables and show the label, which is also an alternative to see it on small screens
i got the main idea from @QuantNomad
//SPANISH
Este indicador muestra dos tablas, con 10 activos cada una, pueden ser divisas, acciones o cryptos, las columnas se pueden cambiar a la información que quieras ver, entre las opciones están precio o cambio (cambio en porcentaje de la vela en la temporalidad donde lo estes viendo), TL son señales de compra o venta según estrategia de trading latino (Squeeze momentum combinado con ADX) compra si el momentum cambia a rango o subida y el ADX tiene pendiente negativa, venta si el momentum cambia a rango o caída y el ADX tiene pendiente negativa, las señales no son 100% efectivas debes apoyarla con la acción del precio y especulación del mercado, direccionalidad en el momentum, pendiente del ADX, si hay divergencia en el squeeze momoentum, lux algo y cipher utilizan un indicador de Lazy bear, lux algo da señal cuando dos wave trend se cruzan y el cipher da señal cuando el wave trend cruza por encima o debajo del punto 0.
Puedes elegir entre ver una o dos tablas, esto para que se pueda ver en pantallas pequeñas, también esta la opción de ocultar las tablas y mostrar el label, que también es una alternativa para verlo en pantallas pequeñas
La idea principal la tome de @QuantNomad
Gann Square of 9Gann's Square's are some of the best known tools created by Gann. His most well known square was his Square of 9.
The reason for this was because of the symmetry 9 had with itself. Gann was able to balance both price and time with this symmetry.
- 9 is the last single-digit and largest number
- You can add anything to 9 and it will give you a natural number
- (9 + 3 = 12); 1 + 2 = 3... (9 + 9 = 18); 1 + 8 = 9... etc.
- Multiplying any number by 9 will have the natural number be 9
- (9 * 6 = 54); 5 + 4 = 9... (9 * 3 = 27); 2 + 7 = 9... etc.
For these reason, Gann claimed that 9 has everything within itself.
Here I have created an on-chart square of 9 including the cardinal and ordinal cross points colored. In the settings you are able to customize the starting value of the table as well as the period movement. In most cases, 81 is not high enough to be useful in charting cases, so I'd recommend printing out your own Gann Square of 9 that goes as high as you need it to go.
THIS IS NOT TRADING ADVICE ; please use your own technical analysis before making any decisions based off of public indicators. Learn more about Gann's Squares before attempting to use them as this script was not meant to give you answers, only the table.
Fast Fourier Transform (FFT) FilterDear friends!
I'm happy to present an implementation of the Fast Fourier Transform (FFT) algorithm. The script uses the FFT procedure to decompose the input time series into its cyclical constituents, in other words, its frequency components , and convert it back to the time domain with modified frequency content, that is, to filter it.
Input Description and Usage
Source and Length :
Indicates where the data comes from and the size of the lookback window used to build the dataset.
Standardize Input Dataset :
If enabled, the dataset is preprocessed by subtracting its mean and normalizing the result by the standard deviation, which is sometimes useful when analyzing seasonalities. This procedure is not recommended when using the FFT filter for smoothing (see below), as it will not preserve the average of the dataset.
Show Frequency-Domain Power Spectrum :
When enabled, the results of Fourier analysis (for the last price bar!) are plotted as a frequency-domain power spectrum , where “power” is a measure of the significance of the component in the dataset. In the spectrum, lower frequencies (longer cycles) are on the right, higher frequencies are on the left. The graph does not display the 0th component, which contains only information about the mean value. Frequency components that are allowed to pass through the filter (see below) are highlighted in magenta .
Dominant Cycles, Rows :
If this option is activated, the periods and relative powers of several dominant cyclical components that is, those that have a higher power, are listed in the table. The number of the component in the power spectrum (N) is shown in the first column. The number of rows in the table is defined by the user.
Show Inverse Fourier Transform (Filtered) :
When enabled, the reconstructed and filtered time-domain dataset (for the last price bar!) is displayed.
Apply FFT Filter in a Moving Window :
When enabled, the FFT filter with the same parameters is applied to each bar. The last data point of the reconstructed and filtered dataset is used to build a new time series. For example, by getting rid of high-frequency noise, the FFT filter can make the data smoother. By removing slowly evolving low-frequency components (including non-periodic constituents), one can reveal and analyze shorter cycles. Since filtering is done in real-time in a moving window (similar to the moving average), the modified data can potentially be used as part of a strategy and be subjected to other technical indicators.
Lowest Allowed N :
Indicates the number of the lowest frequency component used in the reconstructed time series.
Highest Allowed N :
Indicates the number of the highest frequency component used in the reconstructed time series.
Filtering Time Range block:
Specifies the time range over which real-time FFT filtering is applied. The reason for the presence of this block is that the FFT procedure is relatively computationally intensive. Therefore, the script execution may encounter the time limit imposed by TradingView when all historical bars are processed.
As always, I look forward to your feedback!
Also, leave a comment if you'd be interested in the tutorial on how to use this tool and/or in seeing the FFT filter in a strategy.
Multi ZigZagI created this as basis for my next scripts. We are just trying to plot multiple zigzags with different length basis here. Input allows you to select different Length , Width , Color and Line Style for each Zigzags.
Max_pivot_size says how many pivots each Zigzag can have. Value 100 means, each zigzag will show 99 lines joining 100 points.
Additional option ShowStatsTable allows you to print pivots in a table. Table only shows selected zigzags.
Chaikin Money Flow + MACD + ATRHere I present you on of Trade Pro's Trading Idea: Chaikin Money Flow + MACD + ATR.
This strategy is not as profitable as it can be seen in one of his videos. In the forex market, the strategy could reach a maximum of 35% profitability.
I have, as some of my followers have requested, created an overview of the current position, risk and leverage settings in the form of a table.
Furthermore, one can again swap between short and long positions.
It is now possible to select or deselect individual indicators.
I have chosen the ATR alone as a take profit stop loss, as in his strategy.
A position is only triggered as soon as all prerequisites have been fulfilled and a command is executed. This prevents false triggering by bots and repainting.
-----------------------------------------------------------------------------------
How does the strategy work?
ENTRY
Long
The MACD indicator must be above the zero line.
Then the K line must cross the D line.
Finally, when this happens, the Money Flow Index must be above the zero line.
Short
Contrary to the premise of long positions.
EXIT
ATR Exit
The value of ATR at the time of buying is multiplied by the value entered in "Profit factor ATR" and "Stop factor ATR". As soon as the price reaches this value, it is closed.
Important
The script must be optimized for each coin or currency pair.
I will publish a guide to the strategy shortly. There I will explain how the table works and how to set the strategy correctly.
The results of the strategy are without commissions and leverage.
If you have any questions or feedback, please let me know in the comments.
MTF Technical Ratings [Anan]█ OVERVIEW
This indicator is a modified version of "Technical Ratings" v5.0 available in the public library to provide a quick overview of Technical Ratings in 6 optional timeframes.
█ FEATURES
- Multi-timeframe Table.
- Display Technical Ratings for "MAs" with a percentage.
- Display Technical Ratings for "Oscillators" with a percentage.
- Display Technical Ratings for "All" with a percentage.
- Full control of displaying any row(MAs / Oscillators / All) or any column(Multi-timeframe)
- Full control of Table position and size.
- Full control of displaying any row or column.
ORIGINAL DESCRIPTION ABOUT TECHNICAL RATING v1.0
█ OVERVIEW
This indicator calculates TradingView's well-known "Strong Buy", "Buy", "Neutral", "Sell" or "Strong Sell" states using the aggregate biases of 26 different technical indicators.
█ CALCULATIONS
The indicator calculates the aggregate value of two groups of indicators: moving averages and oscillators.
The "MAs" group is comprised of 15 different components:
• Six Simple Moving Averages of periods 10, 20, 30, 50, 100 and 200
• Six Exponential Moving Averages of the same periods
• A Hull Moving Average of period 9
• A Volume-weighed Moving Average of period 20
• Ichimoku
The "Oscillators" group includes 11 components:
• RSI
• Stochastic
• CCI
• ADX
• Awesome Oscillator
• Momentum
• MACD
• Stochastic RSI
• Wiliams %R
• Bull Bear Power
• Ultimate Oscillator
The state of each group's components is evaluated to a +1/0/-1 value corresponding to its bull/neutral/bear bias. The resulting value for each of the two groups are then averaged to produce the overall value for the indicator, which oscillates between +1 and -1. The complete conditions used in the calculations are documented in the Help Center.
Relative Growth ScreenBased on the Growth Range indicator published here:
Instead of plotting, they are printed in color coded table. Colors say whether the growth rate of these factors are relatively higher or lower.
Similar to quality screen, table positions can be customized.
If you have big enough screen, you can fit both quality and growth screens this way:
s3.tradingview.com
light_logLight Log - A Defensive Programming Library for Pine Script
Overview
The Light Log library transforms Pine Script development by introducing structured logging and defensive programming patterns typically found in enterprise languages like C#. This library addresses a fundamental challenge in Pine Script: the lack of sophisticated error handling and debugging tools that developers expect when building complex trading systems.
At its core, Light Log provides three transformative capabilities that work together to create more reliable and maintainable code. First, it wraps all native Pine Script types in error-aware containers, allowing values to carry validation state alongside their data. Second, it offers a comprehensive logging system with severity levels and conditional rendering. Third, it includes defensive programming utilities that catch errors early and make code self-documenting.
The Philosophy of Errors as Values
Traditional Pine Script error handling relies on runtime errors that halt execution, making it difficult to build resilient systems that can gracefully handle edge cases. Light Log introduces a paradigm shift by treating errors as first-class values that flow through your program alongside regular data.
When you wrap a value using Light Log's type system, you're not just storing data – you're creating a container that can carry both the value and its validation state. For example, when you call myNumber.INT() , you receive an INT object that contains both the integer value and a Log object that can describe any issues with that value. This approach, inspired by functional programming languages, allows errors to propagate through calculations without causing immediate failures.
Consider how this changes error handling in practice. Instead of a calculation failing catastrophically when it encounters invalid input, it can produce a result object that contains both the computed value (which might be na) and a detailed log explaining what went wrong. Subsequent operations can check has_error() to decide whether to proceed or handle the error condition gracefully.
The Typed Wrapper System
Light Log provides typed wrappers for every native Pine Script type: INT, FLOAT, BOOL, STRING, COLOR, LINE, LABEL, BOX, TABLE, CHART_POINT, POLYLINE, and LINEFILL. These wrappers serve multiple purposes beyond simple value storage.
Each wrapper type contains two fields: the value field v holds the actual data, while the error field e contains a Log object that tracks the value's validation state. This dual nature enables powerful programming patterns. You can perform operations on wrapped values and accumulate error information along the way, creating an audit trail of how values were processed.
The wrapper system includes convenient methods for converting between wrapped and unwrapped values. The extension methods like INT() , FLOAT() , etc., make it easy to wrap existing values, while the from_INT() , from_FLOAT() methods extract the underlying values when needed. The has_error() method provides a consistent interface for checking whether any wrapped value has encountered issues during processing.
The Log Object: Your Debugging Companion
The Log object represents the heart of Light Log's debugging capabilities. Unlike simple string concatenation for error messages, the Log object provides a structured approach to building, modifying, and rendering diagnostic information.
Each Log object carries three essential pieces of information: an error type (info, warning, error, or runtime_error), a message string that can be built incrementally, and an active flag that controls conditional rendering. This structure enables sophisticated logging patterns where you can build up detailed diagnostic information throughout your script's execution and decide later whether and how to display it.
The Log object's methods support fluent chaining, allowing you to build complex messages in a readable way. The write() and write_line() methods append text to the log, while new_line() adds formatting. The clear() method resets the log for reuse, and the rendering methods ( render_now() , render_condition() , and the general render() ) control when and how messages appear.
Defensive Programming Made Easy
Light Log's argument validation functions transform how you write defensive code. Instead of cluttering your functions with verbose validation logic, you can use concise, self-documenting calls that make your intentions clear.
The argument_error() function provides strict validation that halts execution when conditions aren't met – perfect for catching programming errors early. For less critical issues, argument_log_warning() and argument_log_error() record problems without stopping execution, while argument_log_info() provides debug visibility into your function's behavior.
These functions follow a consistent pattern: they take a condition to check, the function name, the argument name, and a descriptive message. This consistency makes error messages predictable and helpful, automatically formatting them to show exactly where problems occurred.
Building Modular, Reusable Code
Light Log encourages a modular approach to Pine Script development by providing tools that make functions more self-contained and reliable. When functions validate their inputs and return wrapped values with error information, they become true black boxes that can be safely composed into larger systems.
The void_return() function addresses Pine Script's requirement that all code paths return a value, even in error handling branches. This utility function provides a clean way to satisfy the compiler while making it clear that a particular code path should never execute.
The static log pattern, initialized with init_static_log() , enables module-wide error tracking. You can create a persistent Log object that accumulates information across multiple function calls, building a comprehensive diagnostic report that helps you understand complex behaviors in your indicators and strategies.
Real-World Applications
In practice, Light Log shines when building sophisticated trading systems. Imagine developing a complex indicator that processes multiple data streams, performs statistical calculations, and generates trading signals. With Light Log, each processing stage can validate its inputs, perform calculations, and pass along both results and diagnostic information.
For example, a moving average calculation might check that the period is positive, that sufficient data exists, and that the input series contains valid values. Instead of failing silently or throwing runtime errors, it can return a FLOAT object that contains either the calculated average or a detailed explanation of why the calculation couldn't be performed.
Strategy developers benefit even more from Light Log's capabilities. Complex entry and exit logic often involves multiple conditions that must all be satisfied. With Light Log, each condition check can contribute to a comprehensive log that explains exactly why a trade was or wasn't taken, making strategy debugging and optimization much more straightforward.
Performance Considerations
While Light Log adds a layer of abstraction over raw Pine Script values, its design minimizes performance impact. The wrapper objects are lightweight, containing only two fields. The logging operations only consume resources when actually rendered, and the conditional rendering system ensures that production code can run with logging disabled for maximum performance.
The library follows Pine Script best practices for performance, using appropriate data structures and avoiding unnecessary operations. The var keyword in init_static_log() ensures that persistent logs don't create new objects on every bar, maintaining efficiency even in real-time calculations.
Getting Started
Adopting Light Log in your Pine Script projects is straightforward. Import the library, wrap your critical values, add validation to your functions, and use Log objects to track important events. Start small by adding logging to a single function, then expand as you see the benefits of better error visibility and code organization.
Remember that Light Log is designed to grow with your needs. You can use as much or as little of its functionality as makes sense for your project. Even simple uses, like adding argument validation to key functions, can significantly improve code reliability and debugging ease.
Transform your Pine Script development experience with Light Log – because professional trading systems deserve professional development tools.
Light Log Technical Deep Dive: Advanced Patterns and Architecture
Understanding Errors as Values
The concept of "errors as values" represents a fundamental shift in how we think about error handling in Pine Script. In traditional Pine Script development, errors are events – they happen at a specific moment in time and immediately interrupt program flow. Light Log transforms errors into data – they become information that flows through your program just like any other value.
This transformation has profound implications. When errors are values, they can be stored, passed between functions, accumulated, transformed, and inspected. They become part of your program's data flow rather than exceptions to it. This approach, popularized by languages like Rust with its Result type and Haskell with its Either monad, brings functional programming's elegance to Pine Script.
Consider a practical example. Traditional Pine Script might calculate a momentum indicator like this:
momentum = close - close
If period is invalid or if there isn't enough historical data, this calculation might produce na or cause subtle bugs. With Light Log's approach:
calculate_momentum(src, period)=>
result = src.FLOAT()
if period <= 0
result.e.write("Invalid period: must be positive", true, ErrorType.error)
result.v := na
else if bar_index < period
result.e.write("Insufficient data: need " + str.tostring(period) + " bars", true, ErrorType.warning)
result.v := na
else
result.v := src - src
result.e.write("Momentum calculated successfully", false, ErrorType.info)
result
Now the function returns not just a value but a complete computational result that includes diagnostic information. Calling code can make intelligent decisions based on both the value and its associated metadata.
The Monad Pattern in Pine Script
While Pine Script lacks the type system features to implement true monads, Light Log brings monadic thinking to Pine Script development. The wrapped types (INT, FLOAT, etc.) act as computational contexts that carry both values and metadata through a series of transformations.
The key insight of monadic programming is that you can chain operations while automatically propagating context. In Light Log, this context is the error state. When you have a FLOAT that contains an error, operations on that FLOAT can check the error state and decide whether to proceed or propagate the error.
This pattern enables what functional programmers call "railway-oriented programming" – your code follows a success track when all is well but can switch to an error track when problems occur. Both tracks lead to the same destination (a result with error information), but they take different paths based on the validity of intermediate values.
Composable Error Handling
Light Log's design encourages composition – building complex functionality from simpler, well-tested components. Each component can validate its inputs, perform its calculation, and return a result with appropriate error information. Higher-level functions can then combine these results intelligently.
Consider building a complex trading signal from multiple indicators:
generate_signal(src, fast_period, slow_period, signal_period) =>
log = init_static_log(ErrorType.info)
// Calculate components with error tracking
fast_ma = calculate_ma(src, fast_period)
slow_ma = calculate_ma(src, slow_period)
// Check for errors in components
if fast_ma.has_error()
log.write_line("Fast MA error: " + fast_ma.e.message, true)
if slow_ma.has_error()
log.write_line("Slow MA error: " + slow_ma.e.message, true)
// Proceed with calculation if no errors
signal = 0.0.FLOAT()
if not (fast_ma.has_error() or slow_ma.has_error())
macd_line = fast_ma.v - slow_ma.v
signal_line = calculate_ma(macd_line, signal_period)
if signal_line.has_error()
log.write_line("Signal line error: " + signal_line.e.message, true)
signal.e := log
else
signal.v := macd_line - signal_line.v
log.write("Signal generated successfully")
else
signal.e := log
signal.v := na
signal
This composable approach makes complex calculations more reliable and easier to debug. Each component is responsible for its own validation and error reporting, and the composite function orchestrates these components while maintaining comprehensive error tracking.
The Static Log Pattern
The init_static_log() function introduces a powerful pattern for maintaining state across function calls. In Pine Script, the var keyword creates variables that persist across bars but are initialized only once. Light Log leverages this to create logging objects that can accumulate information throughout a script's execution.
This pattern is particularly valuable for debugging complex strategies where you need to understand behavior across multiple bars. You can create module-level logs that track important events:
// Module-level diagnostic log
diagnostics = init_static_log(ErrorType.info)
// Track strategy decisions across bars
check_entry_conditions() =>
diagnostics.clear() // Start fresh each bar
diagnostics.write_line("Bar " + str.tostring(bar_index) + " analysis:")
if close > sma(close, 20)
diagnostics.write_line("Price above SMA20", false)
else
diagnostics.write_line("Price below SMA20 - no entry", true, ErrorType.warning)
if volume > sma(volume, 20) * 1.5
diagnostics.write_line("Volume surge detected", false)
else
diagnostics.write_line("Normal volume", false)
// Render diagnostics based on verbosity setting
if debug_mode
diagnostics.render_now()
Advanced Validation Patterns
Light Log's argument validation functions enable sophisticated precondition checking that goes beyond simple null checks. You can implement complex validation logic while keeping your code readable:
validate_price_data(open_val, high_val, low_val, close_val) =>
argument_error(na(open_val) or na(high_val) or na(low_val) or na(close_val),
"validate_price_data", "OHLC values", "contain na values")
argument_error(high_val < low_val,
"validate_price_data", "high/low", "high is less than low")
argument_error(close_val > high_val or close_val < low_val,
"validate_price_data", "close", "is outside high/low range")
argument_log_warning(high_val == low_val,
"validate_price_data", "high/low", "are equal (no range)")
This validation function documents its requirements clearly and fails fast with helpful error messages when assumptions are violated. The mix of errors (which halt execution) and warnings (which allow continuation) provides fine-grained control over how strict your validation should be.
Performance Optimization Strategies
While Light Log adds abstraction, careful design minimizes overhead. Understanding Pine Script's execution model helps you use Light Log efficiently.
Pine Script executes once per bar, so operations that seem expensive in traditional programming might have negligible impact. However, when building real-time systems, every optimization matters. Light Log provides several patterns for efficient use:
Lazy Evaluation: Log messages are only built when they'll be rendered. Use conditional logging to avoid string concatenation in production:
if debug_mode
log.write_line("Calculated value: " + str.tostring(complex_calculation))
Selective Wrapping: Not every value needs error tracking. Wrap values at API boundaries and critical calculation points, but use raw values for simple operations:
// Wrap at boundaries
input_price = close.FLOAT()
validated_period = validate_period(input_period).INT()
// Use raw values internally
sum = 0.0
for i = 0 to validated_period.v - 1
sum += close
Error Propagation: When errors occur early, avoid expensive calculations:
process_data(input) =>
validated = validate_input(input)
if validated.has_error()
validated // Return early with error
else
// Expensive processing only if valid
perform_complex_calculation(validated)
Integration Patterns
Light Log integrates smoothly with existing Pine Script code. You can adopt it incrementally, starting with critical functions and expanding coverage as needed.
Boundary Validation: Add Light Log at the boundaries of your system – where user input enters and where final outputs are produced. This catches most errors while minimizing changes to existing code.
Progressive Enhancement: Start by adding argument validation to existing functions. Then wrap return values. Finally, add comprehensive logging. Each step improves reliability without requiring a complete rewrite.
Testing and Debugging: Use Light Log's conditional rendering to create debug modes for your scripts. Production users see clean output while developers get detailed diagnostics:
// User input for debug mode
debug = input.bool(false, "Enable debug logging")
// Conditional diagnostic output
if debug
diagnostics.render_now()
else
diagnostics.render_condition() // Only shows errors/warnings
Future-Proofing Your Code
Light Log's patterns prepare your code for Pine Script's evolution. As Pine Script adds more sophisticated features, code that uses structured error handling and defensive programming will adapt more easily than code that relies on implicit assumptions.
The type wrapper system, in particular, positions your code to take advantage of potential future features or more sophisticated type inference. By thinking in terms of wrapped values and error propagation today, you're building code that will remain maintainable and extensible tomorrow.
Light Log doesn't just make your Pine Script better today – it prepares it for the trading systems you'll need to build tomorrow.
Library "light_log"
A lightweight logging and defensive programming library for Pine Script.
Designed for modular and extensible scripts, this utility provides structured runtime validation,
conditional logging, and reusable `Log` objects for centralized error propagation.
It also introduces a typed wrapping system for all native Pine values (e.g., `INT`, `FLOAT`, `LABEL`),
allowing values to carry errors alongside data. This enables functional-style flows with built-in
validation tracking, error detection (`has_error()`), and fluent chaining.
Inspired by structured logging patterns found in systems like C#, it reduces boilerplate,
enforces argument safety, and encourages clean, maintainable code architecture.
method INT(self, error_type)
Wraps an `int` value into an `INT` struct with an optional log severity.
Namespace types: series int, simple int, input int, const int
Parameters:
self (int) : The raw `int` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: An `INT` object containing the value and a default Log instance.
method FLOAT(self, error_type)
Wraps a `float` value into a `FLOAT` struct with an optional log severity.
Namespace types: series float, simple float, input float, const float
Parameters:
self (float) : The raw `float` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `FLOAT` object containing the value and a default Log instance.
method BOOL(self, error_type)
Wraps a `bool` value into a `BOOL` struct with an optional log severity.
Namespace types: series bool, simple bool, input bool, const bool
Parameters:
self (bool) : The raw `bool` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `BOOL` object containing the value and a default Log instance.
method STRING(self, error_type)
Wraps a `string` value into a `STRING` struct with an optional log severity.
Namespace types: series string, simple string, input string, const string
Parameters:
self (string) : The raw `string` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `STRING` object containing the value and a default Log instance.
method COLOR(self, error_type)
Wraps a `color` value into a `COLOR` struct with an optional log severity.
Namespace types: series color, simple color, input color, const color
Parameters:
self (color) : The raw `color` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `COLOR` object containing the value and a default Log instance.
method LINE(self, error_type)
Wraps a `line` object into a `LINE` struct with an optional log severity.
Namespace types: series line
Parameters:
self (line) : The raw `line` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `LINE` object containing the value and a default Log instance.
method LABEL(self, error_type)
Wraps a `label` object into a `LABEL` struct with an optional log severity.
Namespace types: series label
Parameters:
self (label) : The raw `label` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `LABEL` object containing the value and a default Log instance.
method BOX(self, error_type)
Wraps a `box` object into a `BOX` struct with an optional log severity.
Namespace types: series box
Parameters:
self (box) : The raw `box` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `BOX` object containing the value and a default Log instance.
method TABLE(self, error_type)
Wraps a `table` object into a `TABLE` struct with an optional log severity.
Namespace types: series table
Parameters:
self (table) : The raw `table` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `TABLE` object containing the value and a default Log instance.
method CHART_POINT(self, error_type)
Wraps a `chart.point` value into a `CHART_POINT` struct with an optional log severity.
Namespace types: chart.point
Parameters:
self (chart.point) : The raw `chart.point` value to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `CHART_POINT` object containing the value and a default Log instance.
method POLYLINE(self, error_type)
Wraps a `polyline` object into a `POLYLINE` struct with an optional log severity.
Namespace types: series polyline, series polyline, series polyline, series polyline
Parameters:
self (polyline) : The raw `polyline` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `POLYLINE` object containing the value and a default Log instance.
method LINEFILL(self, error_type)
Wraps a `linefill` object into a `LINEFILL` struct with an optional log severity.
Namespace types: series linefill
Parameters:
self (linefill) : The raw `linefill` object to wrap.
error_type (series ErrorType) : Optional severity level to associate with the log. Default is `ErrorType.error`.
Returns: A `LINEFILL` object containing the value and a default Log instance.
method from_INT(self)
Extracts the integer value from an INT wrapper.
Namespace types: INT
Parameters:
self (INT) : The wrapped INT instance.
Returns: The underlying `int` value.
method from_FLOAT(self)
Extracts the float value from a FLOAT wrapper.
Namespace types: FLOAT
Parameters:
self (FLOAT) : The wrapped FLOAT instance.
Returns: The underlying `float` value.
method from_BOOL(self)
Extracts the boolean value from a BOOL wrapper.
Namespace types: BOOL
Parameters:
self (BOOL) : The wrapped BOOL instance.
Returns: The underlying `bool` value.
method from_STRING(self)
Extracts the string value from a STRING wrapper.
Namespace types: STRING
Parameters:
self (STRING) : The wrapped STRING instance.
Returns: The underlying `string` value.
method from_COLOR(self)
Extracts the color value from a COLOR wrapper.
Namespace types: COLOR
Parameters:
self (COLOR) : The wrapped COLOR instance.
Returns: The underlying `color` value.
method from_LINE(self)
Extracts the line object from a LINE wrapper.
Namespace types: LINE
Parameters:
self (LINE) : The wrapped LINE instance.
Returns: The underlying `line` object.
method from_LABEL(self)
Extracts the label object from a LABEL wrapper.
Namespace types: LABEL
Parameters:
self (LABEL) : The wrapped LABEL instance.
Returns: The underlying `label` object.
method from_BOX(self)
Extracts the box object from a BOX wrapper.
Namespace types: BOX
Parameters:
self (BOX) : The wrapped BOX instance.
Returns: The underlying `box` object.
method from_TABLE(self)
Extracts the table object from a TABLE wrapper.
Namespace types: TABLE
Parameters:
self (TABLE) : The wrapped TABLE instance.
Returns: The underlying `table` object.
method from_CHART_POINT(self)
Extracts the chart.point from a CHART_POINT wrapper.
Namespace types: CHART_POINT
Parameters:
self (CHART_POINT) : The wrapped CHART_POINT instance.
Returns: The underlying `chart.point` value.
method from_POLYLINE(self)
Extracts the polyline object from a POLYLINE wrapper.
Namespace types: POLYLINE
Parameters:
self (POLYLINE) : The wrapped POLYLINE instance.
Returns: The underlying `polyline` object.
method from_LINEFILL(self)
Extracts the linefill object from a LINEFILL wrapper.
Namespace types: LINEFILL
Parameters:
self (LINEFILL) : The wrapped LINEFILL instance.
Returns: The underlying `linefill` object.
method has_error(self)
Returns true if the INT wrapper has an active log entry.
Namespace types: INT
Parameters:
self (INT) : The INT instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the FLOAT wrapper has an active log entry.
Namespace types: FLOAT
Parameters:
self (FLOAT) : The FLOAT instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the BOOL wrapper has an active log entry.
Namespace types: BOOL
Parameters:
self (BOOL) : The BOOL instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the STRING wrapper has an active log entry.
Namespace types: STRING
Parameters:
self (STRING) : The STRING instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the COLOR wrapper has an active log entry.
Namespace types: COLOR
Parameters:
self (COLOR) : The COLOR instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the LINE wrapper has an active log entry.
Namespace types: LINE
Parameters:
self (LINE) : The LINE instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the LABEL wrapper has an active log entry.
Namespace types: LABEL
Parameters:
self (LABEL) : The LABEL instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the BOX wrapper has an active log entry.
Namespace types: BOX
Parameters:
self (BOX) : The BOX instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the TABLE wrapper has an active log entry.
Namespace types: TABLE
Parameters:
self (TABLE) : The TABLE instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the CHART_POINT wrapper has an active log entry.
Namespace types: CHART_POINT
Parameters:
self (CHART_POINT) : The CHART_POINT instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the POLYLINE wrapper has an active log entry.
Namespace types: POLYLINE
Parameters:
self (POLYLINE) : The POLYLINE instance to check.
Returns: True if an error or message is active in the log.
method has_error(self)
Returns true if the LINEFILL wrapper has an active log entry.
Namespace types: LINEFILL
Parameters:
self (LINEFILL) : The LINEFILL instance to check.
Returns: True if an error or message is active in the log.
void_return()
Utility function used when a return is syntactically required but functionally unnecessary.
Returns: Nothing. Function never executes its body.
argument_error(condition, function, argument, message)
Throws a runtime error when a condition is met. Used for strict argument validation.
Parameters:
condition (bool) : Boolean expression that triggers the runtime error.
function (string) : Name of the calling function (for formatting).
argument (string) : Name of the problematic argument.
message (string) : Description of the error cause.
Returns: Never returns. Halts execution if the condition is true.
argument_log_info(condition, function, argument, message)
Logs an informational message when a condition is met. Used for optional debug visibility.
Parameters:
condition (bool) : Boolean expression that triggers the log.
function (string) : Name of the calling function.
argument (string) : Argument name being referenced.
message (string) : Informational message to log.
Returns: Nothing. Logs if the condition is true.
argument_log_warning(condition, function, argument, message)
Logs a warning when a condition is met. Non-fatal but highlights potential issues.
Parameters:
condition (bool) : Boolean expression that triggers the warning.
function (string) : Name of the calling function.
argument (string) : Argument name being referenced.
message (string) : Warning message to log.
Returns: Nothing. Logs if the condition is true.
argument_log_error(condition, function, argument, message)
Logs an error message when a condition is met. Does not halt execution.
Parameters:
condition (bool) : Boolean expression that triggers the error log.
function (string) : Name of the calling function.
argument (string) : Argument name being referenced.
message (string) : Error message to log.
Returns: Nothing. Logs if the condition is true.
init_static_log(error_type, message, active)
Initializes a persistent (var) Log object. Ideal for global logging in scripts or modules.
Parameters:
error_type (series ErrorType) : Initial severity level (required).
message (string) : Optional starting message string. Default value of ("").
active (bool) : Whether the log should be flagged active on initialization. Default value of (false).
Returns: A static Log object with the given parameters.
method new_line(self)
Appends a newline character to the Log message. Useful for separating entries during chained writes.
Namespace types: Log
Parameters:
self (Log) : The Log instance to modify.
Returns: The updated Log object with a newline appended.
method write(self, message, flag_active, error_type)
Appends a message to a Log object without a newline. Updates severity and active state if specified.
Namespace types: Log
Parameters:
self (Log) : The Log instance being modified.
message (string) : The text to append to the log.
flag_active (bool) : Whether to activate the log for conditional rendering. Default value of (false).
error_type (series ErrorType) : Optional override for the severity level. Default value of (na).
Returns: The updated Log object.
method write_line(self, message, flag_active, error_type)
Appends a message to a Log object, prefixed with a newline for clarity.
Namespace types: Log
Parameters:
self (Log) : The Log instance being modified.
message (string) : The text to append to the log.
flag_active (bool) : Whether to activate the log for conditional rendering. Default value of (false).
error_type (series ErrorType) : Optional override for the severity level. Default value of (na).
Returns: The updated Log object.
method clear(self, flag_active, error_type)
Clears a Log object’s message and optionally reactivates it. Can also update the error type.
Namespace types: Log
Parameters:
self (Log) : The Log instance being cleared.
flag_active (bool) : Whether to activate the log after clearing. Default value of (false).
error_type (series ErrorType) : Optional new error type to assign. If not provided, the previous type is retained. Default value of (na).
Returns: The cleared Log object.
method render_condition(self, flag_active, error_type)
Conditionally renders the log if it is active. Allows overriding error type and controlling active state afterward.
Namespace types: Log
Parameters:
self (Log) : The Log instance to evaluate and render.
flag_active (bool) : Whether to activate the log after rendering. Default value of (false).
error_type (series ErrorType) : Optional error type override. Useful for contextual formatting just before rendering. Default value of (na).
Returns: The updated Log object.
method render_now(self, flag_active, error_type)
Immediately renders the log regardless of `active` state. Allows overriding error type and active flag.
Namespace types: Log
Parameters:
self (Log) : The Log instance to render.
flag_active (bool) : Whether to activate the log after rendering. Default value of (false).
error_type (series ErrorType) : Optional error type override. Allows dynamic severity adjustment at render time. Default value of (na).
Returns: The updated Log object.
render(self, condition, flag_active, error_type)
Renders the log conditionally or unconditionally. Allows full control over render behavior.
Parameters:
self (Log) : The Log instance to render.
condition (bool) : If true, renders only if the log is active. If false, always renders. Default value of (false).
flag_active (bool) : Whether to activate the log after rendering. Default value of (false).
error_type (series ErrorType) : Optional error type override passed to the render methods. Default value of (na).
Returns: The updated Log object.
Log
A structured object used to store and render logging messages.
Fields:
error_type (series ErrorType) : The severity level of the message (from the ErrorType enum).
message (series string) : The text of the log message.
active (series bool) : Whether the log should trigger rendering when conditionally evaluated.
INT
A wrapped integer type with attached logging for validation or tracing.
Fields:
v (series int) : The underlying `int` value.
e (Log) : Optional log object describing validation status or error context.
FLOAT
A wrapped float type with attached logging for validation or tracing.
Fields:
v (series float) : The underlying `float` value.
e (Log) : Optional log object describing validation status or error context.
BOOL
A wrapped boolean type with attached logging for validation or tracing.
Fields:
v (series bool) : The underlying `bool` value.
e (Log) : Optional log object describing validation status or error context.
STRING
A wrapped string type with attached logging for validation or tracing.
Fields:
v (series string) : The underlying `string` value.
e (Log) : Optional log object describing validation status or error context.
COLOR
A wrapped color type with attached logging for validation or tracing.
Fields:
v (series color) : The underlying `color` value.
e (Log) : Optional log object describing validation status or error context.
LINE
A wrapped line object with attached logging for validation or tracing.
Fields:
v (series line) : The underlying `line` value.
e (Log) : Optional log object describing validation status or error context.
LABEL
A wrapped label object with attached logging for validation or tracing.
Fields:
v (series label) : The underlying `label` value.
e (Log) : Optional log object describing validation status or error context.
BOX
A wrapped box object with attached logging for validation or tracing.
Fields:
v (series box) : The underlying `box` value.
e (Log) : Optional log object describing validation status or error context.
TABLE
A wrapped table object with attached logging for validation or tracing.
Fields:
v (series table) : The underlying `table` value.
e (Log) : Optional log object describing validation status or error context.
CHART_POINT
A wrapped chart point with attached logging for validation or tracing.
Fields:
v (chart.point) : The underlying `chart.point` value.
e (Log) : Optional log object describing validation status or error context.
POLYLINE
A wrapped polyline object with attached logging for validation or tracing.
Fields:
v (series polyline) : The underlying `polyline` value.
e (Log) : Optional log object describing validation status or error context.
LINEFILL
A wrapped linefill object with attached logging for validation or tracing.
Fields:
v (series linefill) : The underlying `linefill` value.
e (Log) : Optional log object describing validation status or error context.
